Dev-t (developed or wrong traffic) destroys any real production in an org while making the org seem frantically busy.

The words “policy,” “plans,” “programs,” “projects” and “orders” are often used interchangeably one for the other, incorrectly.

The downfall of HCO was THE FAILURE TO POLICE DEV-T.

To handle any confusions on the words and substance of “policy,” “plans,” “programs,” “projects” and “orders” the following DESCRIPTIVE DEFINITIONS (see Sen Logic No. 5) are laid down for our use.

The CAUSE of DEV-T is UNHATTEDNESS.

POLICY: By this is meant long-range truths or facts which are not subject to change expressed as operational rules or guides.

People who do not know what they are supposed to do or produce take on traffic that does not belong to them, originate traffic they have no business with and send it to wrong terminals who don’t handle.

PLANS: Short-range broad intentions as to the contemplated actions envisaged for the handling of a broad area to remedy it or expand it or to obstruct or impede an opposition to expansion. A plan is usually based on observation of potentials (or resources) and expresses a bright idea of how to use them. It always proceeds from a REAL WHY if it is to be successful.

Not knowing their hats or posts, they refer things they should handle to others who don’t handle them either. The org loads up with not-dones and half-dones and backlogs.

PROGRAM: A series of steps in sequence to carry out a plan. One usually sees a program following the discovery of a Why. But in actual fact a plan had to exist in the person’s mind, whether written or not, before a program could be written. A program, thus, carries out the plan conceived to handle a found WHY. A plan and its program require authorization (or okay) from the central or coordinating authority of the general activities of a group before they can be invested in, activated or executed.

People who should refer what they know don’t originate at all and sit on hot emergencies and leave them unhandled. And if they do send them on, not knowing the org board, they send them to the wrong terminals. And if they send it to the right terminal, it goes in a way it can’t be handled for lack of comm expertise.

PROJECTS: The sequence of steps written to carry out ONE step of a program. Project orders often have to be written to execute a program step. These should be written but usually do not require any approval and often are not generally issued but go to the person or persons who will accomplish that step of a program. Under the category of PROJECT would come orders, work projects, etc. These are a series of GUIDING STEPS which if followed will result in a full and successful accomplishment of the program target.

This goes for any type of particle — despatches, letters, bodies, money, customers, materials, supplies, any particle.

ORDERS: The verbal or written direction from a lower or designated authority to carry out a program step or apply the general policy.

Problems are brought to seniors instead of Completed Staff Work (requiring a recommendation).

In short:

DEV-T means an UNHATTED, UNTRAINED, OFF-POLICY STAFF.

POLICY = the rules of the game, the facts of life, the discovered truths and the invariable procedures.

It means loads of overwork and little production or income.

PLANS = the general bright idea one has to remedy the WHY found and get things up to the ideal scene or improve even that. (Approval.)

AND DEV-T AND UNHATTEDNESS MEAN THAT THE PERSON AT THE TOP OF A DEPARTMENT, DIVISION OR THE ORG HAS TO SINGLE-HAND.

PROGRAM = the sequence of major actions needed to do the plan. (Approval.)

It isn’t an org, it’s a mob.

PROJECT = the sequence of steps necessary to carry out one step in a program. (No approval.)

Unhatted staff “go criminal,” so Ethics will be very heavy.

ORDERS = some program steps are so simple that they are themselves an order or an order can simply be a roughly written project.

Thus, by these definitions a data analysis would look like this:

A first action for an executive or any terminal is to demand CORRECT COMM.

POLICY: (What brings the evaluation into existence in the first place.)

In its basic elements this means

SITUATION: (Departure from or improvement of the ideal scene expressed in policy.)

1. The staff member originates things that apply or are the business of HIS OWN POST. (On-origin.)

DATA: (Observations leading to INVESTIGATION.)

2. The origin is sent to the right terminal that handles that. (On-line.)

STATISTICS: (The independent continuing survey of production or lack of it.) WHY: (The real reason found by the investigation.)

3. If a post is supposed to originate, it does so. (Communicates.)

IDEAL SCENE: (The state of affairs envisioned by policy or the improvement of even that.)

4. If a problem is encountered, it is forwarded ONLY with a full recommendation for handling. (Completed Staff Work or CSW.)

HANDLING:

5. One does NOT accept a comm that is not the post business of the originator. (Enforces on-origin.)

A PLAN whether written in full or not based on the WHY to use the resources available to move the existing scene toward the ideal scene.

6. One does NOT accept a comm that does not belong to him. (Enforces on-line.)

A PROGRAM: A sequence of broad steps to get the plan executed.

7. One insists that a post should originate, or do the duties, or furnish the product or service of that post. (Enforces correct action.)

PROJECTS: Any sequence of steps ordered or written to get a program step completed.

8. One never accepts a problem unless it has with it a sound recommendation by the originator accompanying it. (Enforced CSW.)

ORDERS: The program step itself or the verbal or written project to get the program step fully done.

9. One demands specific names and instances, not generalities. (Nonsuppressive comm.)

Thus a handling could look like this:

10. One demands full particulars, not half-reports or vague generalities. (Nonsuppressive comm.)

HANDLING:

11. One demands Comm be in proper form. (Correct despatch or completed.)

Plan: To use Bob Bartlett to replace the incompetent exec found in the WHY.

12. One has a place to receive the Comm. (In-basket or place in org.)

1. Find a replacement for Bartlett. PERSONNEL.

13. One has to have a place to put the comm for delivery. (Out-basket or comm center.)

2. Program Bob Bartlett to get his incomplete cycles caught up. DIR OF PERSONNEL ENHANCEMENT.

14. One has to have standard lines and routes for particles to follow. (Comm system or lines.)

3. Train Bob Bartlett. DIR OF TRAINING.

15. One demands use of the system — 1 warning, 1 admin cramming, 1 retread as an expeditor or in Estates to redo basics — for frequent offenders.

4. Write Garrison Mission Orders for Bartlett. ACTION MISSION WRITER.

16. One demands HATTEDNESS and people performing the duties of their posts!

5. Write recall orders for G. Zonk (the incompetent found in the WHY). PERSONNEL.

17. One demands an up-to-date Org Board and Staff drilled on it.

6. Send Bartlett to relieve Zonk. ACTION.

18. One NEVER STALEDATES. He handles when he is expected to.

7. On Zonk’s return assign to bilge cleaner. PERSONNEL.

19. One does NOT go soft in the head or get reasonable or find exceptions. THERE IS NO SUBSTITUTE FOR CORRECT COMM AND CORRECT LINES.

his of course is a very simple plan and simple program.

The orders are seen as “PERSONNEL,” “DIR OF PERSONNEL ENHANCEMENT,” “ACTION MISSION WRITER,” etc., at the paragraph ends. The program step itself is an ORDER to the person or unit named at program step end. But IT ALSO AUTHORIZES THAT PERSON OR UNIT TO DO THE STEP OR ISSUE ORDERS TO DO THE STEP OR EVEN WRITE A PROJECT AND GET IT DONE.

An org that has no Comm discipline is a madhouse. It will be expensive. It will produce very little. It will try to deliver overt products.

That final end word on the program step is an AUTHORITY as well as being an order to the person or unit named.

And it will drive its execs up the chimney.

The immediate result will be a conclusion on the part of the execs, “These blankety-blank-blanks are doing us in!” “The place is full of suppressive people.” “These guys are no-good bums!” And, “Start shooting.”

A copy of a full program marked MASTER is placed in a folder. The folder is marked on the edge with the program name and number. The program itself is stapled along its left edge to the inside left cover of the folder.

Heavy ethics and offloads occur. These are almost always the result of a whole org gone around the bend from Dev-T.

A “Flag Rep” is responsible for “LRH programs.” A Deputy Executive Director or Deputy Commanding Officer is responsible for an ED’s or C/O’s programs.

Accidents happen. People get ill.

The responsibility lies in seeing that each step is FULLY effectively DONE.

And the place falls apart.

All related papers, copies of projects’ orders, etc., are collected in that folder and as each done is reported and investigated as DONE it is marked off on the MASTER program sheet.

When all those projects or orders bred by the program steps are DONE then the PROGRAM is considered DONE.

The only known cure is TRAINING and HATTING.

One does not “report progress” but only DONES and when something is NOT done yet it is chased up by the “Flag Rep” or Deputy ED or C/O and “debugged.”

For years we underestimated the number of persons needed to train and hat a staff. The whole civilization has troubles because it hasn’t even known about hatting, much less that it took someone to do it.

Any failure of HCO was caused by its drowning in Dev-T, even at last generating it because it never had enough people devoted to training and hatting, getting in org lines and comm lines.

The word “bugged” is slang for snarled up or halted.

HCO can do its job relieved of the whole burden of hatting.

DEBUG is to get the snarls or stops out of it.

The Solution is THE ESTABLISHMENT OFFICER.

This itself requires an evaluation. The evaluation may be done at a glance or it may take a full formal evaluation by form.

This person operates in a division, not under its secretary but under a senior Establishment Officer.

The ideal scene here is the program step DONE or even improved.

He performs the duties of the departments of HCO for that division.

So the WHY here would be the REAL reason it was not being done or couldn’t be done and that may require hours to locate and sometimes days to remedy.

In a small org it requires a trained Establishment Officer for Divisions 7, 1 and 2 and another for Divisions 3, 4, 5 and 6.

When “debugging” one usually finds the persons assigned the target already have a “WHY” and it is usually a false Why for if it was the right one the program step would get done.

In a larger org there is one in charge of all Establishment Officers and an Establishment Officer in each division.

Thus debugging usually begins with finding “their Whys” — which is to say reasons, excuses, apologies, etc. Getting these into view is a main part of the program step evaluation.

As the org grows, the larger divisions get assistant Establishment Officers to the divisional one.

A project, often written, comes out of this DEBUG EVALUATION.

They do not establish and run away. They establish and maintain the division staff, personnel hats, posts, lines, materiel and supplies.

In extreme cases it will be found that the whole program is based on a wrong WHY and rapidly needs redoing by the original authority. Example: The WHY found was that the JINX OFFICE WAS NOT MAKING MONEY. In doing one step of the program: “3. Survey past invoices to find where money is coming from and why they don’t get it now. MISSION,” the mission sent finds Jinx Office was making money by the ton but it was being wasted by their having bought a huge building whose rent is three times normal rental “in the hopes new subtenants would pay the rent but nobody wants the place.” Rapid debug is needed because the target can’t really be done. They ARE making money and they do get it now.

Their first job is to get staff working at their posts producing something and their next task is TO DRIVE DEV-T OUT OF EXISTENCE IN THAT ORG.

In such a case doing the program unearthed a new REAL WHY and scrubbed that program.

A super-frantic hysterical communication would be sent to the authority of the

The booms and depressions of orgs, their successes and fall-aparts are signaled by

program, “New WHY found by Pgm 891 target 3 observation. Jinx Office paying $80,000 a quarter for skyscraper. Obvious real Why ED has delusions of grandeur, is a bad business head. Suggest Pgm 891 redone on new Why and suggest plan of mission here for instant offload of this skyscraper and office into proper quarters and replacement of ED.” At which the Flag Rep" or Deputy ED or Deputy C/O will approach the authority for the pgm to get immediate cancellation of 891 and all program targets and a new Program 891R based on the REAL REAL WHY.

Debug, however, is not always so dramatic. “We don’t have anyone to put on it” is the usual excuse as they sit lazily chatting amongst their piled up dev-t.

The underlying cause is unhattedness.

So one evaluates the area against the program target and finds a WHY that, executed as a project will get that target done.

So we are dealing in Dev-T with a symptom. Like any disease, it soon catches up with the body of the org and its health.

The PERFECT DEBUG EVALUATION (a) gets the target done (b) improves the area (c) leaves no dregs of human emotion and reaction behind it.

Dev-t is an expression of untrained, unhatted staff. It shows they do not do the functions of their posts regardless of how busy or exhausted they are.

Just plain screaming often works. But if one has to, there is a real WHY there someplace that should be found, a project handed out and done.

And most important for an executive to know: There is seldom any malice in it. It is just confusion. Even new people or new execs coming in to such an area all full of enthusiasm and bushy-tailed will cave in from the fantastic do-less motions of such an org.

Morale will be bad because PRODUCTION IS THE BASIS OF MORALE and who can produce in the midst of all that noise????

You can find out all the SITUATIONS and WHYS in the world but if there isn’t a PLAN and PROGRAM and if these are not DONE fully, then nothing beneficial will happen. Indeed the not-dones, half-dones and backlogs will mount up (per HCO P/L 26 Jan 72, Admin Know-How 29, Executive Series 5) and set the whole thing a step backwards.

The place will go into apathy and tiredness as one is hit all day with OFF-LINE, OFF-ORIGIN COMM.

Bad programs and clumsy projects develop useless traffic (dev-t) and tie people up all over the place, pull them off normal needful actions and send the existing scene even further from the ideal scene. They make people very busy but nothing beneficial is gained and as the useless actions distract from normal duties, the whole place is at risk.

The executive’s solution is to HAT, HAT, HAT; and get help hatting, hatting, hatting; get the org board up and DRILL, DRILL, DRILLED. Demand, demand, demand the products of the post the person holds and only those products. And police his lines and get the dev-t in his own area handled, handled, handled; and never, never, never pull dev-t blunders himself; and ALWAYS, ALWAYS, ALWAYS DO AND INSIST UPON CORRECT COMM.

Staffs subjected to programs that are not based on sound observation evaluation, a REAL WHY and the points in Data Series 23, become apathetic as they see no result.

The solution is do what you can and all you can to hat and reduce dev-t and scream for an Establishment Officer to save the org.

So programs that are bad and programs that are right but don’t get fully done are alike deadly. THERE IS NO SUBSTITUTE FOR CORRECTLY DONE DATA ANALYSIS.

CORRECT COMM IS THE SYMPTOM OF A HEALTHY, PRODUCING ORG AND A VALUABLE EXECUTIVE AND STAFF MEMBER.

THERE IS NO EXCUSE FOR NOT GETTING CORRECT PROGRAMS DONE.

In this way and only in this way can one raise the existing scene toward an ideal scene.

Data analysis is a powerful tool. YOU CAN USE IT.

[See also HCO PL 9 May 1974. Prod-Org, Esto and Older Systems Reconciled, on page 446. which modifies the above Policy Letter.]